home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Netware Super Library
/
Netware Super Library.iso
/
nov_info
/
nw386
/
acct-7.386
next >
Wrap
Text File
|
1989-07-24
|
9KB
|
225 lines
Chapter 7
Accounting Services
This chapter on Accounting Services includes the
following sections:
■ Introduction
■ Properties
■ Audit File
■ Activity Log
■ Audit Trail System
Introduction
NetWare Accounting Services allows a server to charge for
the use of its services. For example, a database server
can charge for the number of records viewed, the number
of requests serviced, or the amount of connect time. A
print server can charge for the number of pages printed.
The file server supervisor determines the charge for each
type of service, and the file server bindery stores the
list of authorized accounting servers and each client's
accounting information. Once a server is listed as an
authorized accounting server and has logged in, it can
perform the following accounting tasks:
■ Submit a charge to a client's account
■ Place a hold against a client's account
■ Query a client's account status
■ Maintain a trail of charges in an audit file Properties
To perform the tasks listed above, Accounting Services
uses three properties in the file server's bindery to
store the object IDs of all authorized accounting servers
as well as information about each client's account. These
three bindery properties and details about the
information they contain are discussed below.
ACCOUNT_SERVERS Property
Each server object must have an ACCOUNT_SERVERS property
when accounting is enabled. This property contains the
bindery object ID of every server authorized to submit
accounting records to that server. For example, before
server PRINT_SERVER can submit charges to server SALES,
its object ID must be listed in the ACCOUNT_SERVERS
property of server SALES. (Any object that is security-
equivalent to an object in the ACCOUNT_SERVERS property
can also submit accounting records.)
The ACCOUNT_SERVERS property is of type set and has
security access levels equal to a supervisor. If a file
server object has no ACCOUNT_SERVERS property, servers
should assume that accounting is disabled, and no charges
for services are made.
ACCOUNT_BALANCE Property
Each object that can log in (meaning it has a PASSWORD
property) must have an ACCOUNT_BALANCE property. An
object's account balance and minimum balance are stored
in this property. Servers can deny services to an object
if the object has no ACCOUNT_BALANCE property.
The ACCOUNT_BALANCE property is of type item and has
read-object and write-supervisor security access levels.
The account balance places a general limitation on a
client's use of all network resources. However,
Accounting Services does not provide any method for
placing a ceiling on a client's use of a particular
resource or service.
The account balance usually represents some monetary unit
such as cents. The system administrator must ensure that
all servers submit their charges using the same monetary
unit. If an object's account balance has no more funds,
servers should refuse further service. However, if
service has already been rendered, the server can charge
for it even though no funds are in the account balance.
Setting the minimum balance to 80000000h (the most
negative signed long integer) indicates the object has
no minimum balance, in which case service should never
be refused.
ACCOUNT_HOLDS Property
An authorized server can place a hold on a client's
account, submit a charge to a client's account, and query
a client's account status. Each object that can log in
(meaning it has a PASSWORD property) can have an
ACCOUNT_HOLDS property. If there are holds against a
client's account, they are stored in the ACCOUNT_HOLDS
property. If there are no holds on the account, this
property is not present. The ACCOUNT_HOLDS property is
dynamic, of type item, and has read-object and write-
supervisor security access levels.
The server can place a hold on a client's account before
a request is serviced to ensure that the client has
sufficient funds to pay for service. If the hold
succeeds, this indicates the client has sufficient funds.
The server can then perform the requested service, submit
a charge for the service, then release the amount placed
on hold.
If the hold, along with all other holds, require more
funds than exist in the client's account (client's funds
have gone below minimum balance), the hold request fails.
The requested service should then be refused. An attempt
to hold also fails if 16 other servers have already
placed holds on a client's account.
If the server does not place a hold on an account to
ensure the client has sufficient funds, the server should
query the account before rendering service. Then, if the
client's account is empty, the request for service should
be refused.
If a holding server is disconnected, the hold it had on
a client's account is cleared. The holding server can
also explicitly clear a hold. If a server submits
multiple holds, they accumulate into one hold.
Audit File
In addition to monitoring a network by charging,
querying, or holding a client's account, Accounting
Services offers a method for monitoring network resources
by keeping an audit trail of all charges. The audit file
has normal attributes and resides in the SYS:SYSTEM
directory. File servers can submit charges for connection
time, requests made, blocks read, blocks written, and
disk storage.
Activity Log
In addition to the accounting features of NetWare 386
v3.0, the v3.1 release will feature a supervisor and
workgroup manager Activity Log that records supervisor
and workgroup manager activity on the file server.
Audit Trail System
NetWare 386 v3.1 release will also feature the NetWare
Audit Trail System, thus allowing read and write
auditing. The Read and Write Audit files record
information about who reads from and writes to a database
file. Write auditing makes continuous backup possible,
and the combination of read and write auditing provides
for greater security. Since audit trails are coupled
tightly with transaction tracking, the NetWare Audit
Trail System is available only in systems that support
TTS.
Being coupled tightly with transactional files also
prevents audit information for a transaction from being
written to the audit trail file until after a transaction
is completely applied. The information written to the
audit trail file also gives the capability to roll
forward.
Roll forwarding consists of taking the most recently
archived copy of a file and applying all the write
transactions that have occurred to the file since it was
last archived. Roll forwarding also requires a new
utility to support the audit trail file.
When a file server supporting the NetWare Audit Trail
System comes up, it creates an audit trail file to which
it writes all audit trail information. This file grows
continually and should be regularly archived and deleted
to prevent it from filling the volume. Archiving can be
done automatically by an archive server or manually with
a utility. While the audit trail file is being archived,
the file server should close the active audit file and
create a new audit file.
If the volume containing the audit trail file fills up,
audit trailing is turned off automatically and a warning
message issued. Later, if space is made available for the
audit trail and audit trailing is turned back on, files
still cannot be rolled forward beyond the point where
audit trailing was discontinued because there would be
a gap in the audit trail.
Audit trailing occurs only with files that have their
read or write audit flag bit set. This bit is modified
using the NetWare FLAG utility, or under program control
by the application. Files with their read audit flag bit
set will have all read requests audited. For each read
request received, the following type of information is
recorded in the audit trail file:
■ User doing the read
■ Time and date of the read
■ File being read
■ File offset of the read
■ Number of bytes read
Files with their write audit flag bit set will have all
write requests audited. For each write request received,
the following type of information will be recorded in the
audit trail file:
■ User doing the write
■ Time and date of the write
■ File being written
■ File offset of the write
■ Number of bytes written
■ Data that was written
■ Transaction number